前言

在上個篇章Day-17已經又提及Pod，也知道Pod為Kubernetes cluster當中最小的執行單位，然後一個Pod當中會有著一個或多個Containers，這些Containers彼此共享著這個pod的資源與端口port，並且互相能以localhost找到其他pod所expose的port。

在這章節除了詳細介紹Pod之外，還會介紹與Pod有著相當淵源的ReplicaSet與Deployment，那我們開始吧！

What is Pod?

Pod又稱豆莢，中間的小豆豆指的就是容器，一個Pod能有一到多個容器，所以Pod是由一組耦合高的容器們組成的容器組，Pod中的所有Containers在共享環境中運行。而這裡的共享環境也衍生出以下幾個特點:

• 所有Containers共享同個IP address與port，意味者容器間彼此能以localhost溝通。
• 所有Containers共享著Volumes，能透過這種方式彼此間溝通。
• 所有Containers共享著檔案系統，能透過這種方式彼此間溝通。
• 所有Containers會被同時地調度。

Pod的生命週期

簡介

Pod也與人一樣有著生老病死，並且Pod與先前介紹的容器一樣是個臨時性的實例，所以不會長期的存在。Pod在被創立時會被予以一個唯一的ID，就像人的身分證字號一樣，並且在創立後被調度到特定節點直到被終止或被刪除前不同地運行著工作。

狀態

Pod有著五個不同的status，分別為Pending、Running、Succeeded、Failed與Unknow。

Tips: 如果某節點死掉或者與集群中其他節點失聯，Kubernetes會實施一種策略，將失去的節點上運行的所有Pod的phase設置為Failed。

Container Status

除了Pod之外，Kubernetes亦會追蹤Pod內每個容器的狀態，一但Scheduler決定將新的Pod分配給指定Node時，Kubelet會開始為該Pod創內裡面所屬的Containers，這些Containers會有著三種不同的狀態，分別為Waiting、Running與Terminated。

至於想要觀察Pod內部容器狀況的話，能夠透過以下指令來獲得資訊。

$ kubectl describe <pod_name/pod_id> -n <namespace>

若不指定namespace則預設為default。

以Pod的Yaml來解析

Kubernetes中的資源創建都是以yaml檔來撰寫，那這邊我們就以下面的範例進行解說。

nginx.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

apiVersion:

kubernetes api version，若versions在1.9以前則使用apps/v1beta2

kind:

Kuberentes通常以kind來分辨此yaml的resource種類，像是pod、service、secret....等

metadata:

這邊主要填寫該pod的訊息資訊，像是Pod的name與Pod的label亦或是annotation等。

spec:

這邊則開始制定該Pod的規格，包含裡頭所擁有的containers，containers分別的名稱、Image、port到掛載的資源與重啟策略、健康檢查...等都包含在此。

deploy pod

那我們現在就以上面的例子來進行部署！

我們先來看一下現行環境與Default Namespace當中，運行的Pod情況。

$ kubectl get pod
No resources found in default namespace.

那我們就來部署了

$ kubectl apply -f nginx.yaml
pod/nginx created

部署完成後我們再來看一下目前的情況

$ kubectl get pod
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          44s

可以看到我們的Pod開始運作了，那這時我們來看一下GKE的後台

最後確認到nginx pod確實部署到GKE上並且狀態為Running，大功告成。

Pod template常用Key-value

image:

image: ghjjhg567/sif:latest

ports:

ports:
 - containerPort: 8100

port bind in the pod，其他containers可在同一pod內用localhost:80來找到它。同時也可以透過連接該pod的service來找到它。

imagePullPolicy:

imagePullPolicy: Always

有Always、IfNotPresent、Never三種選項

• Always: 總是去拉registry的image。(Default option)
• IfNotPresent: 如果本地已經有該image，會優先使用本地，否則才去拉registry。
• Never: 只會使用本地image，若本地無該image則出現異常。

Command

command: ["/usr/src/app/docker_entrypoint.sh"]

類似於Docker中的Entrypoint，每次啟動Container時會最先執行的指令。

resources

resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
  limits:
    cpu: "200m"
    memory: "256Mi"

用來設定container最低需求與最高限制的使用資源。

readinessProbe

readinessProbe:
  httpGet:
    path: /v1/hc
    port: 8100
  initialDelaySeconds: 5
  periodSeconds: 10

健康檢查，並且可以設定web protocol、你health check的endpoint與健康檢查的時間間隔..等設定。P.S 如果健康檢查不過，該Pod是不會變成Running狀態的。

envFrom

envFrom:
  - configMapRef:
      name: django-config
  - configMapRef:
      name: maria-db-config
  - configMapRef:
      name: rabbit-mq-config

可以透過像是configMap或secrets的k8s配置文件，來新增該container的環境變數。

Tips: configMap與secret等在後面篇章會提到。

除了這些外，當然還有很多Template Key&Value，但由於篇幅關係，如果還有其他需求再請去參照官網 https://kubernetes.io/docs/tasks/configure-pod-container/

ReplicaSet

What is ReplicaSet

ReplicaSet的目的是維護一組在任何時候都處於Running狀態的Pod集合，因此，他通常用來穩定維護一定數量的Replicas，確保Pod隨時隨地都在運行。

How the ReplicaSet works

透過Pod上的metadata.ownerReferences連接到選定的Pod，並獲得所選定Pod的ReplicaSet相關訊息。透過訊息得知Pod Set目前的狀態，並依據該狀態進行操作

How to use ReplicaSet

雖然可以透過template type(kind)為ReplicaSet來單獨使用它，但由於它主要是被Deployment用作協調刪除與創建Pod的控制機制，並且在使用Deployment時，不需要特別去管理它，也因此會選擇在使用Deployment時宣告居多。

When to use ReplicaSet

當你需要確保任何時間點都有著指定數量的Pod正在運行著時，就會需要ReplicaSet。然而Deployment是一個更高層級的概念，並且Deployment管理著ReplicaSet，也因此會建議直接使用Deployment就好。

Example

ReplicaSet的yaml階層主要由四大部分組成:

1. ReplicaSet info: apiVersion, kind, metadata這三大部分都是在描述ReplicaSet。
2. replicas:指的是需要保持穩定Running的Pod數量。
3. selector: 創建一個selector並且管理符合標籤的所有pod，也就是範例中的app: nginx標籤。
4. template: 也就是pod的模板，這邊與上面部分pod的書寫方式一致。我們在創立ReplicaSet同時也定義了Pod。

nginx_replicaSet.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx
  labels:
    name: nginx
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

我們接下來執行一下nginx_replicaSet.yaml吧

$ kubectl apply -f nginx_replicaSet.yaml
replicaset.apps/nginx created

接下來觀察一下replicaSet與Pod情形

$ kubectl get pod
NAME          READY   STATUS    RESTARTS   AGE
nginx-76hcb   1/1     Running   0          7m15s
nginx-ctt4q   1/1     Running   0          7m15s
nginx-tx5j9   1/1     Running   0          7m15s

kubectl get replicaset
NAME    DESIRED   CURRENT   READY   AGE
nginx   3         3         3       7m32s

OK, ReplicaSet與Pod都正常運作，那最後我們看一下GKE上工作負載的情況！

確實有了ReplicaSet，並且裡頭的Pod也都運作著，到這邊我們就大功告成了！

小結

這章節我們更深入的談討了Pod，並且以nginx.yaml為例介紹了Pod template基本的撰寫與代表意義，也透過GKE部署了它。之後也介紹了確保Pod Set運行的ReplicaSet，並且也一樣帶一個範例解說。

但礙於篇幅關係，我會將Deployment與Deployment的撰寫放在這個主題的下篇，也請初入Kubernete的大家期待一下，謝謝。

Reference

https://kubernetes.io/docs/concepts/workloads/pods/
https://www.ibm.com/cloud/architecture/content/course/kubernetes-101/deployments-replica-sets-and-pods